# Условие задачи

Ваш отряд встречает ужасного тролля, у которого здоровье равно сумме здоровья всех ваших бойцов,
сила удара и защита равны силе удара и защите самого сильного и защищённого из бойцов,
соответственно, а все остальные характеристики равны минимальной из всего вашего отряда. Как
победить тролля с минимальными потерями? 

В битве урон здоровью после удара вычисляется по формуле: 

(1) Урон1 = |Защита1 + Уклонение1 – Сила_удара2 – Ловкость2|

# Замечания к условию задачи

1. В данном условии на самом деле не нужно пытаться отвечать на поставленный вопрос - этот вопрос, скорее всего, риторического или эмоционального характера.

2. Понятия сцены, отряда и воина являются важными, но мы реализуем их максимально просто: как контейнер контейнеров структур. Это нужно для того, чтобы не отвлекать на них внимания, т.к. в этой задаче нас интересует другое.

3. В формуле урона есть ошибка, но при проектировании нас это не должно волновать, т.к. величина урона будет вычисляться где-то внутри кода и на проектирование не влияет.

# Модель

В данной задаче сразу видно ключевое понятие *боя*, которое хорошо описывается. 

![Неполная модель предметной области](doc/model0.png)

Но модель явно неполна, т.к. неясно, как выполняется *бой*. Например, непонятно условие его окончания, определение победителя и другие особенности.

В данном случае мы имеем дело с неполной моделью. Можно заметить, что не хватает понятия *правил*. По-видимому, автор задачи подразумевал наличие этого понятия, как само-собой разумеющееся. Так бывает довольно часто при постановке задачи.

Следующая проблема в том, что мы не можем определить необходимого нам поведения *правил*. Однако мы можем использовать приём "обратного вывода": начать строить алгоритм реализации *боя* и по ходу дела определять необходимые для него функции *правил*. На блок-схеме ниже розовым обозначено выявленное поведение.

![Алгоритм пошагового боя](doc/algorithm.png)

Важно заметить, что для построения алгоритма *боя* мы сделали одно допущение - реализовали алгоритм пошагового *боя*. Это значит, что поведение *правил* может оказаться неточным, т.к. для других реализаций *боя* выявленного поведения может быть недостаточно. Будем иметь это в виду. Скорее всего, в будущем не обойтись без изменения интерфейсов. Но лучше так, чем никак. 

Также можно заметить, что неточность в определении поведения *правил* будет нивелирована гибким подходом к разработке. Если он применяется.

![Модель предметной области](doc/model.png)

# Реализация модели

В реализации модели использовался интерфейс отображения, чтобы реализацию понятий предметной области изолировать от реализации отображения. 

# Компиляция

```bush
./gomake
```

# Запуск

```bush
bin/test
```
